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SUMMARY 


A comprehensive software control and system configuration management process 
for flight-critical digital control systems of advanced aircraft has been developed 
and refined to ensure efficient flight system development and safe flight operations. 
Because of the highly complex interactions among the hardware, software, and system 
elements of state-of-the-art digital flight control system designs, a systems-wide 
approach to configuration control and management has been used. Specific procedures 
are implemented to govern discrepancy reporting and reconciliation, software and 
hardware change control, system verification and validation testing, and formal doc- 
umentation requirements. An active and knowledgeable configuration control board 
reviews and approves all flight system configuration modifications and revalida- 
tion tests. This report includes examples of configuration management forms and a 
description of the tracking process which ensures accurate and consistent records. 
This flexible process has proved effective during the development and flight test- 
ing of several research aircraft and remotely piloted research vehicles with digital 
flight control systems that ranged from relatively simple to highly complex, inte- 
grated mechanizations. 


INTRODUCTION 


The complex and integrated nature of the flight-critical digital control sys- 
tems of advanced aircraft necessitates a rigorous software control and system con- 
figuration management process to ensure efficient flight system development and safe 
flight operations. Over the past 10 years, the Dryden Flight Research Facility of 
NASA Ames Research Center has developed and refined a comprehensive configuration 
management process, which has been applied to several research aircraft and remotely 
piloted research vehicles with digital flight control systems that ranged from rela- 
tively simple to complex and highly integrated mechanizations. This flexible proc- 
ess has proved effective for the F-8 digital fly-by-wire (DFBW) and the highly inte- 
grated advanced fighter technology integration (AFTI) F-16 research aircraft, as 
well as the 3/8-scale F-15 spin research vehicle (SRV), the highly maneuverable air- 
craft technology (HiMAT), and the drones for aerostructural testing (DAST) remotely 
piloted research vehicles. 

Various methods and approaches for software control and system configuration 
management have been used successfully, and many have been published in the lit- 
erature. All systems have some unique and dominant characteristics? advanced air- 
craft flight control systems are no exception. Because of the highly complex inter- 
actions among the hardware, software, and system elements of a state-of-the-art dig- 
ital flight control system design, a systems-wide configuration control and manage- 
ment process is necessary. Experience with the development of various advanced 
flight systems has shown that use of separate hardware and software configuration 
control procedures is ineffective for highly integrated flight systems in that many 
of the difficult design, development, and testing issues involve interactions bet- 
ween hardware and software systems. 

This paper describes the process and procedures of a highly successful and effi- 
cient software control and system configuration management technique for advanced 
aircraft digital flight control systems. Experience with several advanced vehicle 
systems is described, and specific examples are given to illustrate the implemen- 
tation process. 



NOMENCLATURE 


AFTI 

CCR 

DAST 

DFBW 

DR 

HiMAT 

PC 

RAV 

SRV 

STR 

WO 


advanced fighter technology integration 
configuration change request 
drones for aerostructural testing 
digital fly-by -wire 
discrepancy report 

highly maneuverable aircraft technology 

program change 

remotely augmented vehicle 

spin research vehicle 

system test report 

work order 


SYSTEM DEVELOPMENT PHASES 


The proper application of a successful software control and system configuration 
management process requires a thorough understanding of the various phases required 
for development of an advanced system. The primary phases for development of an 
integrated digital flight control system for an advanced aircraft are definition of 
requirements/ design, production, and ground and flight test (fig. 1). Recognizing 
that all these phases are likely to require interactive development over the life- 
span of a complex system is critical in the implementation of a configuration manage- 
ment process. 

The definition of requirements typically begins with specification of the broad 
mission requirements and culminates with a conceptual design of the system. The con- 
ceptual design is presented in a comprehensive system specification document which 
describes the overall system characteristics, including the functional requirements 
of the hardware and software. Other requirements defined in this phase include the 
equipment and facilities required for system testing, the staffing plan, and the doc- 
umentation procedures . 

The generation of detailed specification documents outlining specific system 
hardware and software requirements is an initial step of the design phase. These 
documents must satisfy the requirements of the comprehensive system specification 
document. During the design phase, the overall plan for software control and system 
configuration management is defined, and specific procedures and responsibilities 
are established. A series of specification and design reviews is essential for the 
efficient evolution of the system development. 
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After the critical design review is the software and hardware production phase, 
which requires the mechanization of various tools and facilities. Generally, the 
hardware and software elements of a complex system kre initially tested indepen- 
dently using specialized stand-alone equipment and facilities. After functional ver- 
ification tests, the software and hardware elements are integrated for final ground 
testing, overall system validation, and flight qualification tests. A flight readi- 
ness review is conducted prior to flight test evaluations to assess the results of 
the various ground tests and the flight readiness of the vehicle and flight systems. 

To properly manage these phases of development, an overall software control and 
system configuration management process is needed to provide consistent treatment of 
software and hardware elements. This process is designed to include both the soft- 
ware and hardware elements of advanced integrated systems and accommodates the inher- 
ent iterative nature of advanced digital flight control system development. The con- 
cept of a systems-wide approach to configuration control and management (which means 
that the same process is used for both software and hardware system elements) is a 
primary contributor to the successful application of this process on a number of 
highly complex aircraft systems. 


PROCESS DESCRIPTION 


The primary purpose of the software control and system configuration management 
process for flight-critical digital flight control systems is to provide a method 
for efficient flight system development and a procedure for assuring safe flight 
operations. The process is designed to control system configuration changes by man- 
aging the primary system development phases described previously, and to resolve dis- 
crepancies uncovered during system testing. In addition, the configuration control 
process prescribes stringent test and documentation requirements and provides for 
visibility of changes across all involved engineering disciplines through formal 
review procedures . 

The overall software control and systems configuration management process 
(fig. 2) can be divided into four phases, analogous to those of the system develop- 
ment process. Requirements for configuration changes arise from new software or 
hardware system requirements or from discrepancies noted during system analysis or 
test. An important element of this change-in-requirements phase is the documenting 
and reporting of system discrepancies. All system development personnel are respon- 
sible for documenting and reporting all discrepancies, software or otherwise, found 
during system operation and test. A standardized form for discrepancy reporting 
aids the documentation and tracking process. When the discrepancy is discovered, 
the anomalous behavior and the system software and hardware test configuration are 
documented in detail. The cause of the discrepancy and the required fix are usually 
determined at a later time; a method of working around the problem or a temporary 
fix may be incorporated if necessary to continue testing. 

After the change requirements are defined, analyses are undertaken to define and 
then design the required software or hardware modifications. For changes required 
as a result of a system discrepancy, the cause and required fix are indicated on the 
discrepancy report form. A configuration change request form is prepared for any 
change required. Before being implemented, each system hardware or software change 
must be reviewed and approved by the configuration control board which includes soft- 
ware, hardware, systems, operations, and management personnel. This board provides 
the forum for disciplinary and flight test engineers to discuss the changes and 
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their impacts, identify test or retest requirements, and determine the effects of 
the changes on operational procedures or system performance. The configuration con- 
trol board approves, returns for further analysis, or rejects the specific hardware 
and software changes requested and then formally documents the action taken. If a 
system hardware modification is required, a work order form is prepared to provide a 
detailed description of the modification. If a system software modification is 
required, a program bhange notice is prepared to describe the specific change and 
the reason for and impact of the change. 

The primary function of the software control and system configuration management 
process during the production phase is to assure that proper procedures are followed 
in the implementation of the approved changes and that requirements for updated doc- 
umentation are met. A hardware drawing is updated, and after fabrication, the modi- 
fication is inspected for quality assurance and compliance with the work order. The 
software manufacturing process is highly dependent on the specific computer equip- 
ment and software development tools and varies greatly from system to system. An 
important element common to all software production processes is the requirement for 
adherence to formal written procedures detailing specific sequences in the manufac- 
turing process as well as for updating the formal software documentation. 

The configuration management process has an integral function in the testing 
that follows the incorporation of any change. Procedures that govern verification 
and validation test requirements are implemented for both software and hardware mod- 
ifications. Written system verification and validation test reports are required 
for all system elements and for all system changes. The verification test for a 
hardware change includes the visual inspection and continuity check which determines 
that a hardware item is constructed and wired in accordance with the drawing. Hard- 
ware validation involves a series of systems functional tests which are performed to 
qualify the design and its implementation. Software verification is the testing 
process that formally assures that the software is coded in accordance with its 
design specification. The software validation step assures that the specified soft- 
ware change accomplishes the desired objective within acceptable limits and operates 
correctly in the operating environment of the total system. The system validation 
testing often uncovers system discrepancies resulting from the integration of the 
hardware and software. Adherence to an established written policy concerning soft- 
ware reverification and system revalidation testing after a software change is 
required. The documented test results are reviewed by the configuration control 
board for adequacy and completeness before the modified hardware or software is 
released for pre-flight checks and flight testing of the system. 

The configuration control board plays a vital role in a successful software con- 
trol and system configuration management process. The board assures that a coordi- 
nated closed-loop process exists at all system development stages by controlling sys 
tern configuration changes arising from new requirements or discrepancy reconcilia- 
tions and by reviewing implementation details and test results. An active and knowl 
edgeable configuration control board greatly enhances the efficiency of complex and 
integrated system developments by maintaining the essential common thread of knowl- 
edge and experience. 


Documentation 

An essential part of the software control and system configuration management 
process is a comprehensive and consistent method for documenting developmental 
changes. The primary goal of this documentation is to provide communication and 
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therefore visibility of changes across all involved engineering disciplines. The 
documentation generated during the validation and test phases of the system develop- 
ment process provides the means by which conformance to the overall mission require- 
ments is tracked and controlled. The material generated for the various design and 
readiness reviews is also a valuable documentation element. 

A method for ^'checks and balances" is provided on the forms used for system con- 
figuration control documentation arid tracking (fig. 3). Closing the loop on the 
change control process is essential in the development of a complex flight system. 

To assure that changes are tracked, tested, and documented properly, the discrepancy 
report, configuration change request, program change, work order, and system test 
report forms are cross-referenced. Each form has a unique identification number to 
aid this cross-referencing process. Examples of the forms used are included in the 
appendix. 

The closing action section on the discrepancy report form provides space for 
recording the configuration change request, program change, and work order numbers 
identifying the implemented change. The configuration change request form cross- 
references all the other forms and is the primary form used for assuring that the 
change has been implemented and documented properly. The program change form used 
for software changes references the discrepancy report and configuration change 
request numbers. In addition, specific software release identification and docu- 
mentation updates are referenced on this form. The work order form includes a ref- 
erence to the discrepancy report if the change is the result of a system discrepancy 
and also provides for documentation of the quality assurance inspection. Hardware 
drawing updates are generally attached to the work order form. The system test 
report forms are used for documenting all formal system testing and the retesting 
required after system changes. For tests resulting from the implementation of sys- 
tem changes, the program change or work order number is referenced. 


Status and Tracking 

An advanced flight system development program commonly has a large number of dis- 
crepancies, changes, and tests in various stages of resolution, design or analysis, 
and accomplishment, respectively. An efficient method of tracking progress and gen- 
erating status information is required for overall project management and scheduling 
purposes. Manual recordkeeping and documentation control may be adequate for sim- 
pler system development projects, but becomes cumbersome and ineffective on larger, 
more complex projects. 

An automated method for maintaining tracking and status information for complex 
flight system configuration modifications has been developed using a microprocessor- 
based computer system. Standard data-base management software is used to create 
files containing all pertinent information required to track system configuration 
status. The computer system is used to store, update, and retrieve information per- 
taining to the status of discrepancy reports, configuration change requests, program 
changes, work orders, and system verification/validation test reports. Hardware 
and software documentation updates are also tracked. Various sorting and indexing 
methods are used to generate hard-copy status reports in a variety of formats. This 
automated system has proved to be an accurate and efficient tool in the overall soft- 
ware control and system configuration management process. 
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APPLICATION EXPERIENCE 


The process for software control and system configuration management has been 
applied to several research aircraft and remotely piloted research vehicle programs, 
including the F-8 DFBW, AFTI/F-16, HiMAT, F-15 SRV, and DAST. All these vehicles 
have integrated digital flight control systems; the mechanization complexity varies 
greatly. The key elements of the process were adapted for specific application on 
each of these programs, demonstrating the flexibility of the overall concept. The 
point at which the formal configuration control process begins varies from program 
to program but generally starts when the baseline system configuration has matured 
to the point of allowing efficient formal testing without undue restrictions or 
operational difficulties. The software control and system configuration management 
methods described in the previous section represent the current status of a continu- 
ally evolving process; experiences from each program contribute refinements and 
enhance both the overall approach and specific procedures. The process, as detailed 
in figure 2, is certainly not envisioned to be directly applicable for all programs; 
however, it has provided a basic framework from which useful configuration control 
and management procedures have been developed. 

The configuration control process. used on the highly complex AFTI/F-16 air- 
craft was largely based on these concepts. Over 100 flights were accomplished and 
13 major software releases were developed and qualified for the AFTI/F-16 digital 
flight control systems during the first year of flight testing. More than 330 dis- 
crepancy reports were processed during the development and flight test activity, and 
over 95 software program changes were implemented. Specific details of the config- 
uration control process used on the AFTI/F-16 aircraft program are contained in 
reference 1. The following sections outline application experience on the F-8 DFBW 
and HiMAT research programs; the experiences with the F-15 SRV and DAST programs 
were similar. 


F-8 DFBW Program 

The F-8 DFBW research aircraft was first flown in 1972 with a simplex, full- 
authority, digital flight control system using ultrareliable system hardware from the 
Apollo spacecraft program and a triply-redundant analog backup system. The first 
flight of the second phase of the F-8 DFBW program, which occurred in 1976, used a 
triply redundant, full-authority digital flight control system for primary control 
and a triplex analog backup system. The flight qualification and validation exper- 
ience gained on the F-8 DFBW flight program is described in reference 2. The com- 
mitment to remove the aircraft's mechanical control system before the initial flight 
test forced the development of a comprehensive set of qualification procedures, 
including a process for software control and system configuration management. This 
early process, which stressed rigorous testing procedures and formal documentation, 
provided the basis for the current process. 

The triply redundant primary flight control system of the F-8 DFBW was designed 
as a flexible research testbed, and has allowed many flight control and system 
research experiments to be investigated in flight. In over 6 years of active flight 
testing and nearly 150 flights, a total of 40 software releases have been qualified 
and used in ground and flight tests. 1 The software control and system configuration 
management system has been used successfully to track over 500 discrepancy reports 
and to process more than 320 program changes to the onboard flight-critical software. 


The F-8 DFBW aircraft also has the capability to use a remotely augmented 
vehicle (RAV) flight test technique for investigating advanced control law con- 
cepts in a cost-effective manner. The RAV concept (ref. 3) uses a ground-based, 
FORTRAN-programmable digital computer for control law computations and up and down 
telemetry links to allow complete closed- loop control. The technique was designed 
to provide the flexibility and versatility necessary to investigate advanced or 
highly speculative control concepts in flight. The onboard flight software treats 
the simplex RAV interface and mechanization as another flight control mode and con- 
tains the necessary validity checks required to maintain overall system integrity. 

The RAV ground computer system and software configurations were developed and 
managed using the same process as was used for the onboard software and flight sys- 
tems. The system testing approach was modified slightly to account for the less 
critical nature of the RAV ground systems and software. The systems -wide approach 
to software control and systems configuration management made the accommodation of 
the additional RAV software and system hardware elements a relatively easy task. 

The process thus demonstrated its inherent flexibility to accommodate and manage 
complex system hardware and software elements that might be added to an advanced 
aircraft flight system after the initial development phase. 


HiMAT Program 

The HiMAT program was conceived to demonstrate advanced technology concepts 
through flight tests of scaled aircraft using a remote piloting technique. Advanced 
composite structures, aeroelastic tailoring, a digital integrated propulsion control 
system, reduced static stability, and a microprocessor-based digital fly-by-wire con- 
trol system are all elements of the HiMAT program. Closed-loop primary flight con- 
trol is performed from a ground-based cockpit, using a digital computer and up and 
down telemetry links. A backup flight control system for emergency operation resides 
in an onboard computer. The onboard systems, which are designed to provide fail- 
safe or better capabilities/ use two microcomputers/ dual uplink receiver/decoders, 
and redundant hydraulic actuation and power systems . 

The HiMAT system development and flight qualification was a complex, highly 
integrated task (ref. 4). Four independent flight-control digital computers, all 
with different software programs, were required to meet the research program objec- 
tives. The two ground-based computers were programmed in FORTRAN, and the two 
onboard computers were programmed in assembly language. The software development 
facilities, verification tools, and ground support equipment used for system valida- 
tion testing were specific to each computer system. The various computer hardware 
and software elements were quite diverse, yet the overall flight system functions 
were highly integrated. A coordinated and consistent software and system develop- 
ment process was essential in the qualification and flight test activities. 

In over 4 years of development and ground and flight test activities, 30 soft- 
ware releases were generated for the 2 onboard computers, 24 software releases for 
the primary ground computer, and 11 software releases for the other ground computer. 
Nearly 500 discrepancy reports were written and resolved, over 320 work orders were 
processed for flight system hardware modifications, and over 480 program changes 
were incorporated in the various software elements. In general, the HiMAT program 
used the outlined discrepancy reporting, software change, and system verification/ 
validation test procedures quite rigorously. However, the system hardware modifica- 
tion process was tailored to respond to the many unique and dynamic requirements of 
the HiMAT flight system development. In particular, many of the system hardware 
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changes did not require the review and approval of the configuration control board? 
the cognizant systems engineer authorized the modifications directly. Any major 
flight control system hardware modifications and those of an integrated-systems 
nature were processed according to the established procedures for overall system 
configuration management. As an illustration of the iterative nature of an advanced 
system development project, the system development history of the HiMAT program is 
summarized in figure 4. 1 

The software control and system configuration management process proved to be an 
effective and efficient method to track, document, and manage this advanced aircraft 
system development activity. The capability of this process to accurately and effi- 
ciently manage the development of a highly integrated flight system containing multi- 
ple, diverse subsystems with an overall systems-wide approach was again demonstrated. 

CONCLUDING REMARKS 


An effective software control and system configuration management process for 
flight-critical digital control systems of advanced aircraft has been described 
and illustrated* The process has been successfully applied to a number of programs 
involving research aircraft and remotely piloted research vehicles with advanced 
flight control systems. Key factors to be considered in the development of a soft- 
ware control and system configuration management process that works include: 

1. The highly complex interactions among the hardware, software, and system 
elements of a state-of-the-art digital flight control system design require that a 
systems-wide approach be used for configuration control and management. 

2. Application experience has shown that maintenance of separate hardware and 
software configuration control procedures is ineffective for highly integrated 
flight systems in that many of the difficult design, development, and testing issues 
involve interactions between hardware and software systems. 

3. The implementation of a configuration management process must account for 
the fact that all the primary system development phases are likely to require itera- 
tive development over the lifespan of a complex flight system. 

The primary purpose of the software control and system configuration management 
process for, flight-critical digital control systems is to provide a method for effi- 
cient system development and a process for assuring safe flight operations. The 
principal elements of the process include: (1) procedures for reporting, tracking, 

and reconciling all system hardware and software discrepancies? (2) a structured 
process for identifying, reviewing, and implementing system hardware and software 
configuration changes? (3) rigorous system verification and validation test proce- 
dures? (4) accurate and consistent documentation requirements? and (5) an active and 
knowledgeable configuration control board to review and approve all system configu- 
ration modifications. 

The effectiveness and flexibility of this software control and system configura- 
tion management process has been demonstrated in use on several advanced flight sys- 
tem development programs of varying complexity and diverse configurations. 
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APPENDIX - CONFIGURATION MANAGEMENT FORMS 


This appendix includes examples of typical forms used in the systems configura 
tion management documentation and tracking process: Discrepancy Report/ Configura 
tion Change Request, Work Order, Program Change, and System Test Report. 



PART A -AIRCRAFT /FACILITY PORTION OF DR 


I (5> ACFT/FACIUTY: 


DISCREPANCY REPORT (DR) 

-REPORT GROUND-BASED OR AIRBORNE PROBLEM 
WITH HARDWARE, SOFTWARE, OR ASSOCIATED OPERATION. 

-SEE PROCESS SPECIFICATION 00-7 FOR DETAILS 


(9) DISCREPANCY - Ust ALL symptoms: 


| (10) MO/DY/YR 1 (11) FLT/OP HRS I (12) FW STATUS | (13) SIGNATURE/ORG/SITE 


FAILURE 1ST SUSPECT 


I (14) FINDINGS OF DETAILED FAILURE ANALYSIS - Root Csusss: 


I (IS) MO/DY/YR | (16) FLT/OP HRS I (17) FW STATUS 9 (18) SIGNATURE/ORG/SITE 


FAILURE CAUSE FOUND - DttsHt Lillsd Abovi 
(19) CORRECTIVI A. CLOSING ACTIONS: 


I (20) PCN'S, OCR'S WO'S, ptc. 1(21) MO/DY/YR I (22) FLT/OP HRS ■ (23) FW STATUS I (24) 8IGNATURE/0RB/SITE 


ACFT/FACIUTY CLOSEOUT ACTION COMPLETE 
(28) ACFT/FACIUTY CL08E0UT SIGNATURE: 


(28) ACFT/FACIUTY CLOSEOUT SIGNATURE 


PART B - P SUB-ASSY PORTION OF DR. USE FOR HARDWARE OR SOFTWARE. USE 1 PART B FOR EACH MAJOR OR LOWER ASSY 


1(33) ITEM PART NO: 


1(34) ITEM SER NO: 


(35) DISCREPANCY - Lltt ALL symptoms not previously listed: . 
FAILURE 1ST SUSPECT 


1(36) MO/DY/YR I (37) OP HRS/CYC I (38) FW STATUS I (39) SIGNATURE/ORG/SITE 


(40) FINDINGS OF DETAILED FAILURE ANALYSIS - List Undines not previously listed: 


I (41) MO/DY/YR I (42) OP HRS/CYC I (43) FW STATUS I (44) SIGNATURE/ORG/SITE 


FAILURE CAUSE FOUND - DETAILS LISTED ABOVE 

(45) CORRECTIVE & CLOSING ACTIONS NOT PREVIOUSLY LISTED: 


I (48) PCN'S, CCR'S, WO’S, etc. 1 (47) MO/DY/YR 1 (46) OP HAS/CYC 1 (49) FW STATUS ■ (50) SIGNATUAE/ORO/SITE 


ITEM CLOSEOUT ACTION COMPLETE 


I (51) ITEM CLOSEOUT SIGNATURE: 


1 (54) ITEM CLOSEOUT SIGNATURE: 


f.l 



CONFIGURATION CHANGE 


REQUEST 


PROJECT 

INITIATOR 

ORGANIZATION 

DATE 

PROJECT TEAM REP. 

D.R. NO. (REF.) 

W.O. NO. (REF.) 

P.C. NO. (REF.) 



REQUEST: 


EVALUATION AND ASSESSMENT 


APPROVE □ DISAPPROVE □ RETURN FOR ANALYSIS □ 

FOR RELEASE CC ^OFFICIAL DATE 





















(1) DATE OF REOUEST: 

(4) DATE REQUIRED: 

(8) ORIGINATOR: 

(10) PROJECT: 

(12) APPROVALS: (a) 

signature title 

lb) 

signature title 

" (13) I 
ITEM No. 


(2) WORK ORDER NUMBER: 


(5) STARTED: 


( 6 ) 


(3) SUB-TASK: 


COMPLETED: 


(7) INSP: 


TELEPHONE: 


(9) TO: 


(11) ATTACHMENTS: 

NO YES 

(c) 


If YES , list each attachment 
at BOTTOM of WORK ORDER 


date 


signature 

Id) 


[signature 

(14) 

DESCRIPTION OF WORK 


title 


date 


title date 


(15) 

(16) 

(17) 

DATE 

TECH. 

INSP. 


LIST ATTACHMENTS 


ORIGINATOR 


















PROGRAM CHANGE 

SOFTWARE CHANGE CONTROL 


REQUEST 

NOTICE 

IF REQUEST, DATE DOCUMENTATION UPDATED 




SIG: 

DATE: 


TITLE DATE 

CHANGE TOREL [s/N ORIGINATOR/ORG. 

DRNO MODULES/SUB ROUTINES CHANGED 

SPECIFICATION REV. NO VERIFICATION AND VALIDATION COMPLETE: 
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SYSTEM TEST REPORT 



CONCLUSIONS 


SIG: 




DR ISSUED 



CONT'D 
ON PAGE. 


W.O. NO. (REF.) PC NO. (REF) 
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Figure 3 * Documentation flow and tracking process • 
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The testing and acguisiticn process for the AN/ARN-101 
avionics system for navigation and weapons delivery on the 
P/RF-4 fighter are outlined. System specifications included 
digital navigation, weapon delivery and reconnaissance 
capabilities, an integrated loran- inertial guidance system, 
all-altitude visual/hlind bombing capability, and integration 
with optical, radar, IR and laser sensors. The ARN-101 
’comprises 14 line replaceable units, e.g«, a digital 
computer, signal-data converter, loran receiver, and a - v ■ 
digital inertial measurement unit. The system also interfaces 
with the Pave Tack external IR sensor laser ranger/desigrator 
pod for target identification/acguisitiop. New specif ications 
were introduced after a fly-off identified a suitable system. 
Four stages of hardware and software test and evaluation 
became necessary for updates and validation. The entire 
process took over a half decade. Delays are attributed to 
modifications being separately managed. o A84-44455 # 

Retrofit of older Military aircraft with new electronic 
systems challenges EBi control engineers MESSER, i. a. 

AA (Teledyne Ryan Electronics, San Diego, CA) SEP. 1983 
7 PAGES 5 REES. EMC Technology (ISSN 0278-4270), 

vol. 2, July-Sept. 1983, p. 41, 42, 44 (4 ff.)« 

Some typical examples of problems encountered in maintaining 
electromagnetic compatibility (EMC) between digital and 
analog electronic eguipment while retrofitting older military 
aircraft are discussed. Consideration is given to the 
difficulties of electronic retrofits with older unique wiring 
systems without incurring substantial cost penalties. Several 
solutions to the problem of limited wires are discussed, 
including not sending analog signals from a voltage source 
over a link which uses a common ground wire and reserving a 
pair of wires for analog signals. Several misconceptions 
concerning the retrofitted wiring system of digital 
microprocessors for managing ground velocity sensor data, 
aircraft heading, altitude and search data, and weapons 
pointing data for older special purpose aircraft are 
discussed. a A84-44691 

Software control and system configuration managements A 
systeas-wide approach National Aeronautics and Space 

Administration. Hugh I. Dryden Flight Research Center, 
Edwards, Calif. National Aeronautics and Space 
Administration. Ames Research Center, Moffett Field, 
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The USAFR-developed GPU Chip Set has been utilized by Tracor 
to implement both USAF and Navy Standard 16-Bit Airborne 
Computer Architectures. Both configurations are currently 
being delivered into DOD full-scale development programs. 
Leadless Hermetic Chip Carrier packaging has facilitated 
implementation of both architectures on single 41/2 x 5 
substrates. The CMOS and CMOS/SOS implementations of the GPti 
Chip Set have allowed both CPU implementations to use less 
than 3 watts of power each. Recent efforts by Tracor for USAF 
have included the definition of a next-generation GPU Chip 
Set that will retain the application- proven architecture of 
the current chip set while offering the added cost advantages 
of transportability across ISO-CMOS and CMOS/SOS processes 
and across numerous semiconductor manufacturers using a 
newly-defined set of common design rules. The Enhanced GPU 
Chip Set will increase speed by an approximate factor of 3 
while significantly reducing chip counts and costs of 
standard CPU implementations. n N84-31157 # 

MIL— STD— 175 Q A as a spaceborne instruction set architecture 
Aerospace Corp», Los Angeles, Calif. CONSTANT, R. N. 
FLEMING, R. C. GARCIA, E. M- LUBCFSKX, OBELL, D. 

fi. In ASD Proc. Papers of the 2nd AFSC Avionics 
Standardization Conf., Vol. 1 p 479-491 (SEE N84-31121 
21-06) NOV. 1982 13 PAGES AD-P003554 AVAIL- 

NTIS HC A25/MF A01 

A study was undertaken to examine the issues involved in 
establishing instruction set architecture (ISA) standards for 
computers used in embedded spaceborne applications on Air 
Force Space Division projects. The specific areas addressed 
were: (1) Space Division requirements and ISA tradeoffs, (2) 
comparisons of military standard and commercial spaceborne 
ISAs, (3) an LSI implementation study, and (4) an LSI cost 
study. The bottom line of the study is that the KIL-STD-1750A 
ISA addresses the onboard processing needs of all present and 
near term Space Division projects as well as many of those on 
far term projects. In addition, the development of space 
gualified 1750A computers should be a low risk project with 
relatively modest costs once the efforts currently sponsored 
by other agencies are successfully completed. n N84-31158 # 
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1ANTIRN software development has successfully demonstrated 
the practicality of language and architecture 
standardization. Savings in schedule and resources directly 
resulted from the transportability of code- While there were 
(and still are) challenges tc standardization, 1ANTIRN has 
proven its eif ectiveness on large, complex, state-of-the-art 
systems. n N84-31 188 # 

Development of a digital air data computer using modern 
microprocessors, hybrid circuits, and pressure sensors with 
freguency output final Report, Dec- 1982 Nord-Micro 
Elektronic Feinmechanik G-m.Jb.H-, Frankfort {West 
Germany). SALDHANN, D . Eonn B undesminist erium fuer 
Forschung und Technclogie HAY 1984 119 PAGES REFS. 

In GERMAN; ENGLISH summary Sponsored iy 
B undesministerium fuer Fcrschung und Technologie 
BMFT-FB-W-84-018 ISSN-034G-7 608 AVAIL- NTIS HC 

A06/HF A0 1 ; Fachinf oimationszentrum , Karlsruhe, West 
Germany Dfl 25 

The development of an'"air data computer according to the 
standard ARINC 7C6 for the Airbus A 310 is reviewed. 

Features, mechanical construction, and software structure of 
the computer are described. The built-in test capability and 
the high reliability are discussed. n N84-312G8 # 

BfiESEX: On board supervision, basic architecture and 

preliminary aspects for payload and space shuttle Interface 
Instituto de Pesguisas Ispaciais, Sao Jose dos Campos 
{Brazil). B2RGANINI, E. W. DEPAUIA, A. B. , JR. 

MARTINS, B. C. £. 0. JUL. 1984 23 PAGES 

Presented at the NASA/INPE Conx. on Brazilian Remote 
Sensing Experiment - ERISEX, Sao Jose dos Campos, 

Brazil, 13-14 Mar- 1S84 Sponsored by NASA 
NASA-CR— 173673 NAS 1.26:173673 INPE-3200-PRE/562 

AVAIL- N1IS HC A02/HR A01 

Data relative to the on board supervision subsystem are 
presented which were considered in a conference between INPE 
and NASA personnel, with the purpose of initiating a joint 
effort leading to the implementation of the Brazilian remote 
sensing experiment - (ERE SEX) . The BRESEX should consist, 
basically, of a multispectr al camera for Earth observation, 
to be tested in a future space shuttle flight, n N84-31271*# 




should be kept out of the direct loop of simulation. The 
following blocks make up the simulation. The thermal model 
block is a classical heat transfer program. It is a 
non-steady state program. The guasistatic block deals with 
problems associated with rigid body control of reflector 
segments. The steady state block assembles data into 
eguations of motion and dynamics. A differential raytrace is 
obtained to establish a change in wave aberrations. The A , 
■observation scene is described. The focal plane module 
converts the photon intensity impinging on it into electron 
streams or into permanent film records. a N84-32317*# 


Some management initiatives to improve embedded commercial 
computer and training device life cycle support Veda, Inc., 
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